home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Apr 89 / T0030-Re Segmentation Cha-Apr89 < prev    next >
Encoding:
Text File  |  1989-04-21  |  1.6 KB  |  43 lines  |  [TEXT/GEOL]
  1. Item    1461510                         20-April-89        10:56
  2.  
  3. From:   ALGER                           Alger, Jeff
  4.  
  5. To:     BIANCHI1                        Bianchi, Curt
  6.         ROLLIN1                         Rollin, Keith A.
  7.         D2215                           Dac SW, Wilma Blair, PRT
  8.  
  9. cc:     MACAPP.TECH$                    MACAPP Tech
  10.  
  11. Sub:    Re- Segmentation Changes?
  12.  
  13. Curt, Keith, and Les,
  14.  
  15. Curt, as usual your observations are right on, this time regarding passing >4
  16. byte instance variables when a heap shuffle may occur.  However, I have a
  17. historical question: why does the Pascal compiler not simply copy such
  18. arguments onto the stack before the call?  Consider the following code
  19. fragment, where fMyInstanceVariable is > 4 bytes:
  20.  
  21. someOtherObject.SomeMethod (SELF.fMyInstanceVariable);
  22.  
  23. This is normally an unstable call, but the compiler could easily have detected
  24. this (it issues an error message now) and copied fMyInstanceVariable onto the
  25. stack as a default behavior.  This avoids code like the following, which is
  26. identical in effect and efficiency, since local variables are also on the
  27. stack:
  28.  
  29. myLocal := fMyInstanceVariable;
  30. someOtherObject.SomeMethod (myLocal);
  31.  
  32. The code of the former is cleaner and does not force the coder to worry about
  33. how many bytes the compiler may choose to use in representing data types; after
  34. all, isn't this one of the advantages of a high-level language?  A compiler
  35. option could warn of such automatic copying and another could turn off the
  36. behavior in situations where you are sure that the call is safe.
  37.  
  38. I would be interested to hear any thoughts on the subject.
  39.  
  40. Jeff Alger
  41.  
  42.  
  43.